EKS Blueprints for Terraformがversion 5になって変わったこと

かずえ

2024.10.31

2022年9月に「EKS x Terraformな人はEKS Blueprintsをチェックしてみて」というブログを書きました。

タイトルの通り、EKSのIaCツールとしてTerraformを使っている場合、terraform-aws-eks-blueprintsリポジトリはとても有用ですよ、という内容のブログです。

Version 5が公開

このEKS Blueprintsリポジトリ、もう1年以上前のことですが、2023年8月10日にVersion 5が公開されました。このメジャーバージョンのアップデートによって、EKS Blueprintsの方針が大きく変わっています。私自身その変更点をちゃんと理解できていなかったので今回まとめました。

Version 4が抱えていた課題点

アドオンとそれをプロビジョニングするツールの組み合わせが多すぎて管理が大変

アドオン = Kubernetes クラスタの機能を拡張するための追加コンポーネントやプラグインのことと捉えてください。例えばCoreDNSだとか、Argo CDだとか、AWS Load Balancer Controllerとかですね。

CNCFのロードマップには約 1,200 のプロジェクト(≒アドオン)がある
アドオンのプロビジョニングに使用されるツールも様々(Terraform、ArgoCD、FluxCD など)

これらの組み合わせの実装およびテストをメンテナンスすることが非常に困難でした。

KubernetesリソースをTerraformでプロビジョニングすることに欠点がある

Terraform はインフラストラクチャをプロビジョニングするための優れたツールです。AWSリソースをプロビジョニングする際に多くの方がTerraformを選択しています。が、Kubernetesクラスター内のリソースをTerraformでプロビジョニングすることについては以下に挙げるようにいくつかの欠点があります。

更新(=同期)タイミングの違い

Terraformは、terraform applyを実行したタイミングでのみ、管理対象のリソースの現状を希望の状態(=Terraformコード)にする更新処理を行ない、エラーが発生すればその処理を停止します。

一方Kubernetesは「Reconciliation Loop」によって継続的にリソースの現状を希望の状態へ更新されるようになっています。

この差が問題になることがあります。

KubernetesではReconciliation Loopによって、たとえ一部リソースのプロビジョニングが失敗したとしてもコントローラー/オペレーターは再試行を続け、再試行の度に成功するプロビジョニングが増えていき、最終的には全て成功するようになります。

Terraformでも、エラーが発生しても何度もapplyを続ければ同じ状況を実現できますが、まあTerraformでエラーが多数発生するような運用は通常しないですよね。

EKSエンドポイントの公開

Terraformでのリソースプロビジョニングはプッシュモデル。クラスターが存在するVPCの外からTerraformコマンドを実行するのが一般的で、これによりEKS エンドポイントのパブリックアクセスを有効にする必要があります。
一方Kubernetes コミュニティで広く受け入れられているアプローチは「プル」ベースのモデルを使用する GitOps。クラスター内部に存在するコントローラー/オペレーターが Git リポジトリからリソース定義をプルし、クラスター内部からプロビジョニングする方針。EKS エンドポイントをパブリックに公開する必要がないので、より安全です。

モジュール構成がややこしい

Terraform 経由でアドオンをプロビジョニングしようとすると、そのアドオンをラップするchild moduleが必要です。

さらに、各アドオン child moduleをまとめて管理するkubernetes-addonsモジュールもありました。

さらにさらに、各child module内ではHelmチャートに関する実装を共通化するために helm-addonモジュールを利用しています。

このあたりの複雑さは以前書いた以下ブログをご覧いただければイメージが掴めるかと思います。

一方、前述のGitOps アプローチの場合はもっとシンプルな方法でプロビジョニングできます。

例: Argo CDでのHelmチャート利用方法 Helm - Argo CD - Declarative GitOps CD for Kubernetes

terraform-aws-eks moduleをラップしている意味があまりない

terraform-aws-modules/terraform-aws-eksというリポジトリがあります。こちらはEKSクラスターをはじめとするEKSの基本的なリソースのプロビジョニングを簡単にするpublished moduleです。

本Blueprintsでも内部でこのterraform-aws-eksモジュールをラップして使っていました。が、ラップする意味合いがあまりないという見解に達しました。直接terraform-aws-eksモジュールを使って、そこで作成されたクラスターに対してBlueprintsを活用してもらえれば良いのです。またこの方針にすることで、eksctlなど別の方法でクラスターを作成した方に対してもBlueprintsを活用していただく可能性が拡がります。

Version 5での変更点

全部乗せのモノリシックな「フレームワーク」から、ユーザーが一連のモジュールコンポーネントを組み合わせて目的を達成することに重点が置かれるようになりました。

terraform-aws-eks moduleと役割が被る部分はやらない

前述の通りversion 4まではterraform-aws-eksモジュールをラップしている部分がありましたが、version 5ではterraform-aws-eksモジュールでできる部分はBlueprintsから削除されました。実装例ではterraform-aws-eksモジュールを利用するようになっています。

そのため、version 4ではリポジトリルートをモジュールのソースにしてクラスターを作成できるようになっていましたが、version 5ではそれができなくなっています。

一部child moduleの削除

aws-kms モジュール
- version 5では terraform-aws-kmsモジュールを使うか、前述のterraform-aws-eksモジュール経由でこのterraform-aws-kmsモジュールを使うことができます。
emr-on-eks モジュール
- terraform-aws-emrが代替になります。

一部child moduleが別リポジトリに移動

irsaとhelm-addon モジュール
- terraform-aws-eks-blueprints-addonに移動されました。
  - terraform-aws-eks-blueprints-addonsという、terraform-aws-eks-blueprints-addonをまとめて管理できるモジュールもあります。
aws-eks-teams モジュール
- terraform-aws-eks-blueprints-teamsに移動されました。

Terraform と ArgoCD の統合の削除→再統合

Terraform と ArgoCD の統合はversion 5初版では削除されました。後により良い方法での統合がリリースされています。それがこちらに書かれているGitOps Bridge Patternのようです。ちょっとパッと理解できなかったので、こちらについてはまた別のエントリでまとめたいと思います。

私にとっての変更のインパクト

「EKS x Terraformな人はEKS Blueprintsをチェックしてみて」に書きましたが、私はBlueprintsを以下2通りの方法で利用していました。

特定の要件の実装例として参考にする
一部モジュールを直接利用する

Version 5になったことの私にとってのインパクトはどれほどなのだろうかと考えてみました。結果、あまり問題ないのでは？と現時点では考えています。

まず、クラスターの作成はもともとterraform-aws-eks moduleで行なっていたので、クラスター作成部分がBlueprintsから削除されることについては問題ありません。
「特定の要件の実装例として参考にする」はversion 5でも patterns/以下を参考にできそうです。
「一部モジュールを直接利用する」については、今後はterraform-aws-eks-blueprints-addonをモジュールソースにすれば良さそうです。もしくはモジュール利用はやめて単に helm_releaseや aws_iam_roleなどを直接書くほうがシンプルで良いかもしれません。